Detection of encrypted packet streams using a timer

ABSTRACT

Methods, systems, and devices are disclosed for detecting encrypted Internet Protocol packet streams. The type of data within an encrypted stream of packets is inferred using an observable parameter. The observable parameter is observable despite encryption obscuring the contents of the encrypted stream of packets. A timer is established that maintains settings despite changes in the type of inferred data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application relates to the commonly assigned and concurrently filed U.S. applications: Ser. No. ______, entitled “Detection of Encrypted Packet Streams” (Attorney Docket BS040215); Ser. No. ______, entitled “Signature Specification for Encrypted Packet Streams” (Attorney Docket BS040216); Ser. No. ______, entitled “Detection of Encrypted Packet Streams” (Attorney Docket BS040278); Ser. No. ______, entitled “Detection of Encrypted Packet Streams Using Process Variation and/or Multiple Processes” (Attorney Docket BS040280); and Ser. No. ______, entitled “Detection of Encrypted Packet Streams Using Feedback Probing” (Attorney Docket BS040281). These commonly-assigned applications are all incorporated by reference.

NOTICE OF COPYRIGHT PROTECTION

A portion of the disclosure of this patent document and its figures contain material subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, but otherwise reserves all copyrights whatsoever.

BACKGROUND

This application generally relates to communications and, more particularly, to inferring data types in encrypted data streams.

Encryption of communications is increasing. More and more people, businesses, and governments are encrypting their electronic communications. This encryption provides enhanced security and privacy for these electronic communications.

Encryption, however, is a problem for communications service providers. Communications service providers need to know the type of data contained within an electronic communication. Some data types receive priority processing, while other data types are queued for later processing. Encryption, however, hides the contents of the communication and often prevents a communications service provider from determining the level of required processing. Because the communications service provider cannot determine the level of required processing, the encrypted communication defaults to lesser priority and/or processing.

Internet telephony provides an example. Internet telephone calls should be processed to result in a real time, or nearly real time, conversation. If packets are lost, or if packets experience congestion, the quality of the call suffers. Internet telephone calls, then, should receive priority processing. When a communications service provider detects data representing an Internet telephone call, the service provider gives that data priority/special processing to reduce packet loss and to reduce latency effects. Encryption, however, hides the contents of the communication. Encryption prevents the communications service provider from determining whether priority and/or special processing is required. So, even though the communication is an Internet telephone call, encryption causes the communication to default to lesser priority and/or processing. The quality of the call may then suffer from packet loss and congestion.

There is, accordingly, a need in the art for improved determination of data types. When parties encrypt their communications, there is a need for determining the type of data contained inside the encrypted communication. There is also a need for identifying a particular kind of encrypted traffic in order to provide prioritized/specialized processing.

SUMMARY

The aforementioned problems, and other problems, are reduced, according to exemplary embodiments, using methods, computer systems, computer programs, and computer program products that detect the type of data contained within an encrypted stream of packets. According to exemplary embodiments, the existence of one or more parameters within the encrypted stream of packets is noted. The one or more parameters are observable, despite encryption obscuring the contents of the encrypted stream of packets. The observable parameters are then used to infer the type of data contained within the encrypted stream of packets. An inference is made whether the encrypted stream of packets contains, for example, video data, picture data, text data, and/or or voice data. According to the exemplary embodiments, a timer is then established that forcibly maintains network and/or system settings, despite a change in the observable parameter and/or the inferred type of data. The timer forces a communications network to disregard instantaneous, dynamic, and/or random changes in the inferred type of data until the timer expires. When the timer expires, the communications network is then able to react to a different type of inferred data. The timer thus prevents the communications network from implementing hasty changes to network settings.

The exemplary embodiments may utilize various values for the timer. The timer maintains a detection state until expiration. The timer may have variable values, depending upon software applications, protocols, data types, equipment vendors, and versions of equipment and/or software. The timer may vary according to time of day, a day of week, or some other schedule. The timer may also vary according to historical conditions, performance objectives and/or conditions, congestion, delay, latency, jitter, packet loss, and other network factors.

The exemplary embodiments infer a type of data within an encrypted stream of packets using an observable parameter. The observable parameter is observable despite encryption obscuring the contents of the encrypted stream of packets. A timer is established that maintains settings until expiration.

Yet more exemplary embodiments describe a system having a communications module that infers a type of data within an encrypted stream of packets using an observable parameter. The observable parameter is observable despite encryption obscuring the contents of the encrypted stream of packets. The communications module also establishes a timer that maintains settings until expiration.

According to another of the embodiments, a computer program product may be used for data types contained within encrypted packet streams. This computer program product includes computer instructions for inferring data types within an encrypted stream of packets using an observable parameter. The observable parameter is compared to a threshold value. Even if the comparison is unfavorable, the computer or communications device continues processing the encrypted stream of packets as if the inferred data were present until expiration of a timer.

The exemplary embodiments may also be used to infer any type of data. The exemplary embodiments may infer the presence of video data, voice data (such as Voice Over Internet Protocol data), picture data, text data, and all other types of data. The exemplary embodiments, for example, may be used to infer the presence of on-line gaming sessions, simulations, virtual reality, email, messaging, multimedia-conferencing, application-sharing, e-voting, group-ware & collaboration, and any sort or type of video data. The exemplary embodiments can be applied to any encrypted stream which still contains observable parameters having some correlation to the type of data and/or the type of application/service and/or the specific application/service. The concepts described herein can help not just the type of data or application being used and communicating within the encrypted stream, but the concepts can also help identify the actual vendor-make, model, and version of a software application being used (e.g., Vendor A may use different packet sizes than Vendor B, and version 3 from Vendor A uses different inter-packet timing than version 1 from Vendor A). Whenever an encrypted stream contains observable parameters, the exemplary embodiments described herein exploit any correlation to the observable parameters.

Other systems, methods, and/or computer program products according to embodiments will be or become apparent to one with skill in the art upon review of the following drawings and detailed description. It is intended that all such additional systems, methods, and/or computer program products be included within this description, be within the scope of the present invention, and be protected by the accompanying claims.

DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the embodiments of the present invention are better understood when the following Detailed Description is read with reference to the accompanying drawings, wherein:

FIG. 1 is a schematic illustrating the exemplary embodiments;

FIGS. 2 and 3 are flowcharts illustrating a method of detecting encrypted packet streams, according to more exemplary embodiments; and

FIG. 4 is a flowchart illustrating a method of detecting encrypted Voice Over Internet Protocol data, according to even more exemplary embodiments.

DETAILED DESCRIPTION

Exemplary embodiments will now be described more fully hereinafter with reference to the accompanying drawings, in which exemplary embodiments are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein. These embodiments are provided so that this disclosure will be thorough and complete and will fully convey the scope of the invention to those of ordinary skill in the art. Moreover, all statements herein reciting embodiments of the invention, as well as specific examples thereof, are intended to encompass both structural and functional equivalents thereof. Additionally, it is intended that such equivalents include both currently known equivalents as well as equivalents developed in the future (i.e., any elements developed that perform the same function, regardless of structure).

Thus, for example, it will be appreciated by those of ordinary skill in the art that the diagrams, schematics, illustrations, and the like represent conceptual views or processes illustrating systems and methods embodying this invention. The functions of the various elements shown in the figures may be provided through the use of dedicated hardware as well as hardware capable of executing associated software. Similarly, any switches shown in the figures are conceptual only. Their function may be carried out through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, the particular technique being selectable by the entity implementing this invention. Those of ordinary skill in the art further understand that the exemplary hardware, software, processes, methods, and/or operating systems described herein are for illustrative purposes and, thus, are not intended to be limited to any particular named manufacturer.

According to exemplary embodiments, the type of data contained within an encrypted stream of packets is detected. A timer is then established that forcibly maintains settings, despite a change in the observable parameter and/or the inferred type of data. The timer forces a communications network and/or communications device to disregard instantaneous, dynamic, and/or random changes in the inferred type of data until the timer expires. When the timer expires, the communications network/device is then able to react to a different type of inferred data. The timer thus prevents the communications network/device from implementing hasty changes to network settings. The timer may also compensate for dynamically unreliable detection and/or dynamism in network performance that may affect detection.

FIG. 1 is a schematic illustrating the exemplary embodiments. A communications module 20 comprises methods, systems, computer programs, and/or computer program products that help provide communications services. The communications module 20 detects an encrypted stream 22 of Internet Protocol packets. The communications module 20 operates within any computer system, such as a communications server 24. The communications module 20 receives the encrypted stream 22 of packets via a communications network 26. Because the stream 22 of packets is encrypted, the encryption obscures the contents of the stream 22 packets. The communications module 20, however, is able to discern one or more observable parameters 28 within the encrypted stream 22 of packets. The communications module 20 is able to observe the parameters 28, despite encryption obscuring the contents 30 of each packet 32 within the stream 22 of packets. Each parameter 28 describes some characteristic that might be observed within the stream 22 of packets, despite the encryption. Although there are many observable parameters, this patent will not describe in detail the observable parameters 28. If the reader desires to learn more about the observable parameters 28, the reader is invited to consult the commonly assigned and concurrently filed U.S. application Ser. No. ______, entitled “Detection of Encrypted Packet Streams” (Attorney Docket BS040215), incorporated herein by reference.

The communications module 20 compares the observable parameters 28 to the actual characteristics of the encrypted stream 22 of packets. The communications module 20 observes the stream 22 of packets and notes whether any of the observable parameters 28 occurs and/or exists within the encrypted stream 22 of packets. The communications module 20 compares the observable parameters 28 to threshold values and infers the type of data contained within the encrypted stream 22 of packets.

Once the type of data is inferred, a timer 34 is established. This timer 34 forces the communications module 20 to maintain the type of inferred data until expiration of the timer 34. The timer 34 helps reduce abrupt and/or hasty network changes due to changing characteristics in the encrypted stream 22 of packets. Even subtle changes within the encrypted stream 22 of packets may cause the communications module 20 to infer a different data type is present. Slight changes in packet sizes, timing intervals, and/or other observable parameters may fool the communications module 20 into thinking the data type has changed. Instantaneous, dynamic, and/or random changes within the encrypted stream 22 of packets could cause the communications module 20 to infer a different type of data is present and, therefore, to change network settings.

The timer 34, however, helps maintain a steady-state of detection. The timer 34 maintains a pseudo-detection state that prevents the communications module 20 from inferring a new type of data until the timer 34 expires. The communications module 20, for example, would continue to infer the presence of Voice Over Internet Protocol data until the timer 34 expires, despite changes in packet sizes, timing intervals, and/or other observable parameters. These changes in the detected observable parameters 28 could cause the communications module 20 to infer a different type of data is present, when this is not actually the case. The timer 34, however, gives the detected values of the observable parameters 28 an opportunity to settle down and confirm that the data type has really changed. The timer 34 thus prevents the communications network 20 from reacting too quickly to changes in the stream 22 of packets.

The timer 34 may have different values for different circumstances. The timer 34 may have any value from a small fraction of a second to hours. The timer 34 may, therefore, have differing values depending upon network conditions, network performance, data types, vendor equipment models and/or manufacturers, software applications, and even times of day and/or days of week. Some protocols, for example, may require different or unique timer values for optimum performance. Some Codec specifications may cause the communications network 26 to be stable, while others produce undesirable or even unstable conditions. The timer 34 may be chosen to help compensate for codec-inspired conditions. The performance of the communications network 26 may change at different times of the day/week, so the timer 34 may be chosen according to a schedule that best suits network conditions. Historical information may cause the communications module 20 to implement different timer values, thus achieving more or less hysteresis, thereby providing appropriate compensation.

The timer 34 may also have a value that varies with other circumstances. Packet congestion, delay, latency, and packet loss within the communications network 26 are all circumstances that may vary the value of the timer 34. A particular vendor's computer equipment, configuration parameters, and even model may require differing/unique timer values. A particular developer's software application may differently perform from another developer's, thus requiring a different timer 34. Even differing protocols may require different timer values.

FIGS. 2 and 3 are flowcharts illustrating a method of detecting encrypted packet streams, according to more exemplary embodiments. An encrypted stream of packets is received (Block 36). An observable parameter is noted (Block 38). The observable parameter is observable despite encryption obscuring the contents of the encrypted stream of packets. The observable parameter is compared to a threshold value or range of values (Block 40). If the comparison is favorable (Block 42), then the type of data within the encrypted stream of packets is inferred using the observable parameter (Block 44). A timer is established (Block 46) and continually checked for expiration (Block 48). Unless the timer has expired (Block 48), the encrypted stream of packets is continually inferred (Block 50), maintained (Block 52), processed (Block 54), and received (Block 36). If, however, the comparison is unfavorable (Block 42)—that is, the comparison does not result in an inference of the data type within the encrypted stream—and if no timer was established (Block 56), then the encrypted stream of packets is continually received and the existence of an observable parameter is continually noted (Blocks 36-42). When the comparison is unfavorable (Block 42) and when the timer is established (Block 56) and not expired (Block 48) is the type of data continually inferred (Block 50), maintained (Block 52), and processed (Block 54), despite a change in the type of inferred data and/or in the observable parameter.

The flowchart continues with FIG. 3. When the comparison is unfavorable, and when the timer expires (Blocks 42 and 48 of FIG. 2), then the value of the timer may be varied according to schedule, performance, congestion, and/or delay (Block 58). The value of the timer may be additionally or alternatively varied according to packet loss, vendor equipment, protocol, and/or software application (Block 60).

FIG. 4 is a flowchart illustrating a method of inferring Voice Over Internet Protocol data in an encrypted stream of packets, according to still more exemplary embodiments. An encrypted stream of packets is received (Block 62). An observable parameter is noted (Block 64). The observable parameter is observable despite encryption obscuring the contents of the encrypted stream of packets. The observable parameter is compared to a threshold value or a range of values (Block 66). If the comparison is favorable (Block 68), then the existence of VoIP data within the encrypted stream of packets is inferred using the observable parameter (Block 70). A timer is established (Block 72) and continually checked for expiration (Block 74). Unless the timer has expired (Block 74), the encrypted stream of packets is continually inferred, maintained, and processed (Block 76), despite any change in the observable parameter. If, however, the comparison is unfavorable (Block 68), and if no timer was established (Block 78), then the encrypted stream of packets is continually received and the existence of an observable parameter is continually noted (Blocks 62-68). When the comparison is unfavorable (Block 68) and when the timer is expired (Block 74), then a new data type may be inferred (Blocks 62-68).

The communications module may be physically embodied on or in a computer-readable medium. This computer-readable medium may include CD-ROM, DVD, tape, cassette, floppy disk, memory card, and large-capacity disk (such as IOMEGA®, ZIP®, JAZZ®, and other large-capacity memory products (IOMEGA®, ZIP®, and JAZZ® are registered trademarks of Iomega Corporation, 1821 W. Iomega Way, Roy, Utah 84067, 801.332.1000, www.iomega.com). This computer-readable medium, or media, could be distributed to end-users, licensees, and assignees. These types of computer-readable media, and other types not mention here but considered within the scope of the present invention, allow the communications module to be easily disseminated. A computer program product for detecting the type of data contained within an encrypted stream of packets includes the communications module stored on the computer-readable medium. The communications module includes computer-readable instructions for inferring Voice Over Internet Protocol data within an encrypted stream of packets using an observable parameter. The observable parameter is observable despite encryption obscuring the contents of the encrypted stream of packets. The communications module continues inferring the existence of the Voice Over Internet Protocol data until expiration of a timer. The communications module continues processing the encrypted stream of packets as if the Voice Over Internet Protocol data were present until expiration of the timer.

The communications module may also be physically embodied on or in any addressable (e.g., HTTP, I.E.E.E. 802.11, Wireless Application Protocol (WAP)) wire line or wireless device capable of presenting an IP address. Examples could include a computer, a wireless personal digital assistant (PDA), an Internet Protocol mobile phone, or a wireless pager.

While the present invention has been described with respect to various features, aspects, and embodiments, those skilled and unskilled in the art will recognize the invention is not so limited. Other variations, modifications, and alternative embodiments may be made without departing from the spirit and scope of the present invention. 

1. A method, comprising the steps of: inferring a type of data within an encrypted stream of packets using an observable parameter, the observable parameter being observable despite encryption obscuring the contents of the encrypted stream of packets; and establishing at least one of a timer and a timer value.
 2. A method according to claim 1, further comprising at least one of the steps of i) maintaining the type of inferred data until expiration of the timer and ii) processing the encrypted stream of packets until expiration of the timer.
 3. A method according to claim 1, further comprising at least one of the steps of i) processing the encrypted stream of packets until expiration of the timer, despite a change in the type of inferred data, ii) maintaining the type of inferred data until expiration of the timer, despite a change in the observable parameter, and iii) applying quality of service processing until expiration of the timer, despite a change in the observable parameter.
 4. A method according to claim 1, further comprising the step of comparing the observable parameter to a threshold value.
 5. A method according to claim 4, wherein if the comparison is unfavorable, maintaining the type of inferred data until expiration of the timer.
 6. A method according to claim 1, further comprising at least one of the steps of i) varying a value of the timer according to a schedule, ii) varying a value of the timer according to performance, iii) varying a value of the timer according to congestion, and iv) varying a value of the timer according to delay.
 7. A method according to claim 1, further comprising at least one of the steps of i) varying a value of the timer according to packet loss, ii) varying a value of the timer according to equipment, iii) varying a value of the timer according to a protocol, and iv) varying a value of the timer according to a software application.
 8. A method according to claim 1, further comprising: inferring Voice Over Internet Protocol data within the encrypted stream of packets using the observable parameter; and continue inferring the Voice Over Internet Protocol data until expiration of the timer.
 9. A system, comprising: a communications module stored in a memory device, and a processor communicating with the memory device; the communications module inferring a type of data within an encrypted stream of packets using an observable parameter, the observable parameter being observable despite encryption obscuring the contents of the encrypted stream of packets; and the communications module establishing a timer.
 10. A system according to claim 9, wherein the communications module at least one of i) maintains the type of inferred data until expiration of the timer and ii) processes the encrypted stream of packets until expiration of the timer.
 11. A system according to claim 9, wherein the communications module at least one of i) processes the encrypted stream of packets until expiration of the timer, despite a change in the type of inferred data, ii) maintains the type of inferred data until expiration of the timer, despite a change in the observable parameter, and iii) applies quality of service processing until expiration of the timer, despite a change in the observable parameter.
 12. A system according to claim 9, wherein the communications module compares the observable parameter to a threshold value.
 13. A system according to claim 12, wherein if the comparison is unfavorable, the communications module maintains the type of inferred data until expiration of the timer.
 14. A system according to claim 9, wherein the communications module at least one of i) varies a value of the timer according to a schedule, ii) varies a value of the timer according to performance of a communications network, iii) varies a value of the timer according to congestion within the communications network, and iv) varies a value of the timer according to delay within the communications network.
 15. A system according to claim 9, wherein the communications module at least one of i) varies a value of the timer according to packet loss within a communications network, ii) varies a value of the timer according to vendor equipment, iii) varies a value of the timer according to a protocol, and iv) varies a value of the timer according to a software application.
 16. A system according to claim 9, wherein the communications module i) infers Voice Over Internet Protocol data within the encrypted stream of packets using the observable parameter, and ii) continues inferring the Voice Over Internet Protocol data until expiration of the timer.
 17. A computer program product comprising a computer readable medium including instructions for performing the steps: inferring a type of data within an encrypted stream of packets using an observable parameter, the observable parameter being observable despite encryption obscuring the contents of the encrypted stream of packets; and establishing a timer.
 18. A computer program product according to claim 17, further performing at least one of the steps of i) maintaining the type of inferred data until expiration of the timer and ii) processing the encrypted stream of packets until expiration of the timer.
 19. A computer program product according to claim 17, further performing at least one of the steps of i) processing the encrypted stream of packets until expiration of the timer, despite a change in the type of inferred data, ii) maintaining the type of inferred data until expiration of the timer, despite a change in the observable parameter, and iii) applying quality of service processing until expiration of the timer, despite a change in the observable parameter.
 20. A computer program product according to claim 17, further performing the steps: inferring Voice Over Internet Protocol data within the encrypted stream of packets using the observable parameter; and continue inferring the Voice Over Internet Protocol data until expiration of the timer. 